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PDES  SCOPE  AND  OBJECTIVES 


PDES  stands  for  Product  Data  Exchange  Standard.  A  Icsig-term  project, 
chaired  by  Kalman  Brauner  of  The  Boeing  Company,  currently  exists  within 
the  IGES  Committee  to  develop  PDES.  This  project  has  two  primary 
objectives: 

1.  to  develop  an  exchange  standard  for  product  data  in  sxipport  of 
industrial  automation 

2.  to  represent  the  US  position  in  the  International  Standards 
Organization  (ISO)  arena  relative  to  the  developnwrnt  of  a  single 
worldwide  standard  for  the  exchange  of  product  data 

A  new  standard  is  being  developed  out  of  the  belief  that  no  existing 
standard  can  be  extended  to  support  industrial  automation  sufficiently 
well. 

"Product  Data"  is  taken  to  be  more  general  than  "product  definition  data*. 
It  includes  data  relevant  to  the  entire  life  cycle  of  a  product: 
manufacturing,  quality  assurance,  testing,  support,  etc.  Industrial 
product  areas  supported  in  previous  exchange  standards  work  within  the  IGES 
Committee  include  mechanical,  electrical,  plant  design,  and  AEC.  While 
there  is  no  inherent  1  imitacioo  in  the  PDES  scope  to  these  areas,  it  is 
naturally  to  be  expected  that  these  areas  will  be  among  the  first  to  be 
addressed  within  PDES. 

Development  of  an  exchange  standard  for  product  data  involves  settling  on  a 
set  of  logical  stnxrtures  to  contain  the  product  data  information,  and  also 
settling  on  the  manner  in  which  these  structures  will  be  implemented  in 
computer  form. 

The  ISO  Technical  Committee  TC  184  (Industrial  Automation  Systems)  and  its 
Subcommittee  SC5  (External  Representation  Of  Product  Model  Data)  are 
relatively  new  committees  within  ISO,  SC4  having  first  met  in  July,  1984. 
The  US  has  the  Secretariat  for  this  Subcommittee.  Brad  Smith  of  the 
National  Bureau  Of  Standards,  is  Chairman  (as  well  as  being  IGES  Chairman). 
Since  that  first  meeting,  events  have  moved  quickly.  There  is  agreement 
within  the  Subcommittee  that  a  sirxgle  worldwide  standard  for  the  exchange 
of  product  data  is  needed.  The  goal  of  the  standard  is  "...the  capture  of 
information  comprising  a  computerized  product  model  in  a  neutral 
form. . .throughout  the  life  cycle  of  the  product".  The  name  of  the  standard 
is  to  be  STEP  -  Standard  for  the  Transfer  and  Exchange  of  Product  Model 
Data.  Technical  work  for  future  versions  of  the  standard  will  be 
accomplished  by  existing  and  future  national  projects.  Technical 
specification  for  the  first  version  of  the  standard  is  targeted  for 
December  31,  1986,  with  effective  industrial  use  targeted  for  1990. 

It  is  the  US  intention  that  PDES  and  STEP  will  be  identical.  At  its  June, 
1985  meeting,  the  IGES  Steering  Committee  unanimously  passed  a  resolution 
that  the  PDES  project  should  represent  US  interests  in  the  STEP  effort. 
Since  that  time,  the  US  TAG  has  requested  that  the  PDES  project  adopt  both 
the  recently  drafted  set  of  detailed  technical  requirements  for  STEP,  and 
also  its  list  of  contents  for  VersicHi  1.0.  Because  of  the  history  of  very 
active  involvement  by  large  nunbers  of  people  within  the  IGES  Committee,  it 


is  expected  that  the  WES  project  will  assume  the  leadership  position  in 
the  STEP  development.  Participating  countries  to  this  date#  besides  tlie 
US#  include:  Canada,  Germany,  Switzerland,  and  the  United  Kingdom.  Japan 
is  expected  to  become  active  soon,  and  has  already  sent  representatives  to 
a  Jerking  Group  meeting  held  in  this  country. 


THE  PDES  RELATIONSHIP  TO  IGES  AND  ITS  DATA  EXCHANGE  HERITAGE 

The  June  1985  meeting  of  the  IGES  Steering  Comnittee  also  outlined  the 
relationship  that  is  to  exist  between  the  IGES  and  the  POES  specificatitxts. 
Work  within  IGES  Technical  Cormittees  will  simultaneously  be  directed 
toward  future,  upward  compatible  versions  of  IGES  and  also  toward  a  draft 
initial  version  of  POES.  IGES  Version  3.0  is  now  in  final  editorial 
review.  The  draft  version  of  POES  is  to  be,  at  a  minumum,  functionally 
equivalent  to  the  then-current  version  of  IGES,  perhaps  Version  4.0.  PDES 
need  not  be  directly  upwardly  compatible  with  IGES,  but  must  accommodate  a 
conversion  path.  When  this  functional  equivalence  exists,  development 
efforts  will  be  directed  toward  PDES,  with  maintainence  efforts  being 
directed  toward  IGES.  It  is  intended  that  this  take  place  by  December  31, 
1986.  An  IGES  Long  Range  Plan,  now  in  draft,  will  further  explain  this 
relationship  and  other  topics  as  well,  such  as  teat  methodology  and 
committee  structure. 

Other  data  exchange  efforts  besides  IGES  Version  4.0  will  affect  Pt^  in 
one  way  or  another.  In  broad  terms,  the  legacy  of  some  of  these  other 
efforts  is  as  follows:  The  IGES  efforts  form  one  "tier",  or  logical 
grouping,  of  efforts.  These  have  data  exchange  between  dissimilar 
interactive  graphics  CAD/CAM  systems  as  their  driving  force.  Early 
versions  were  implicitly  targeted  toward  systems  of  the  70 's  and  early 
80*3,  and  toward  mechanical  applications.  Thus,  from  the  start,  2D 
drawings,  3D  wireframe  models,  and  certain  generative  type  surfaces  were 
emphasized.  With  the  exception  of  those  entities  expressly  intendexJ  for 
tne  drawing  application  area  (eg.,  linear  dimension,  angular  dimension, 
general  note,  etc.),  most  entities  were  generic  (eg.,  line,  arc,  composite 
curve,  associativity),  so  that  the  intent  of  the  exchanged  data  had  to  be 
imposed  from  outside  the  data  itself.  Typically,  this  would  involve  a 
human  viewing  a  representation  of  the  data  on  a  graphics  system,  keying  off 
such  things  as  geometric  shape  or  placement  relative  to  the  part  itself. 
Thus, the  early  versions  of  IGES  were  intended  for  human  oriented 
interpretation  of  the  data  rather  than  for  automated  interpretation  and  use 
of  the  data. 

In  addition  to  additional  geometry  entities,  later  versions  of  IGES  did 
include  application  specific  entities  in  the  Electrical,  FE3i,  and  Plant 
Design  areas.  However,  processors  which  read  and  produce  these  entities 
have  yet  to  see  extensive  use. 

A  second  tier  of  efforts  consists  of  the  CAM-I  XBF-2  effort,  the  IGES  ESP 
effort,  the  ICAM  PDDI  effort,  and  the  follow-on  GMAP  effort  sponsored  by 
the  Air  Force  CIM  Program,  (These  acronyms  denote,  respectively, 
Computer-Aided  Manufacturing-International,  Inc.;  Experimental  Boundary 
File-2;  Initial  Graphics  Exchange  Specification;  Experimental  Solids 
Proposal;  Integrated  Computer  Aided  Manufacturing;  Product  Definition  Data 
Interface;  Geometric  Modelling  Applications  Interface  Program;  Computer 


Integrated  Manufacturing.) 

These  efforts  between  them  bring  tvo  innovations  to  tha  fore,  and  in  effect 
usher  in  a  more  modem  prodixrt  data  exchanr}*  era.  TT>e  first  innovation  is 
the  emphasis  on  a  more  complete  >»efinition  of  the  shape  of  a  part  -  that 
is,  the  emphasis  on  solid  modelling,  in  which  the  set  of  spatial  points 
occupied  by  an  object  is  completely  determined.  In  additlcn  to  this 
complete  "quantitative"  description  of  an  object,  some  systems  a) so  provide 
a  "qualitative"  description  by  decomposing  the  object  into  topological 
entities  such  as  faces,  edges,  and  vertices  which  describe  the  connectivity 
of  the  part.  These  two  types  of  descriptions  are  then  related  by  having 
the  topological  entities  indicate  which  geometry  entities  are  needed  for 
their  definition. 

[Both  the  CAM-I  XBF-2  and  the  IGES  ESP  work  included  entities  for 
boundary  and  CSG  representation  of  solid  objects,  as  well  as 
topological  entities.  The  PDDI  work,  for  which  McDonnell  Douglas 
was  the  prime  contractor,  included  entities  for  boundary 
representation  and  for  topology.  The  PDDI  project  had  as  its 
purpose  the  development  of  a  product  model  and  a  data  exchange 
format  capable  of  conveying  sufficient  design  information  to 
manufacture  a  part.  Four  types  of  aerospace  parts  were  examined. 
Final  demonstrations  for  this  three  year  contract  are  now  being 
conducted.  A  follow-on  effort  sponsored  by  the  Air  Force  CI« 
Program  to  extend  the  PDDI  work  is  the  Geometric  Modeling 
Applications  Interface  Program.  This  effort  is  comparable  in  spirit 
but  larger  in  size  than  the  PDDI  effort,  and  will  be  starting  soon. 
Two  new  classes  of  parts,  and  applications  throughout  tt«  product 
life  cycle  such  as  design,  analysis,  inspection,  arid  product  support 
will  be  considered.  The  new  part  classes  are  turbine  blades  and 
disks.  The  effort  will  also  emphasize  exchange  of  geometric 
modelling  information  between  these  applications,  taking  it  as  a 
given  that  many  different  geometric  modelling  teclmiques  are  used 
across  the  various  applications  areas.] 

The  PDDI  project  went  a  bit  further  than  just  geometry  and  topology 
entities,  identifying  entities  for  other  higher  level  qualitative 
structures  called  part  or  form  "features".  Features  allow  high-level 
concept  communication  cibout  parts.  Examples  are  hole,  flange,  thread,  web, 
pocket,  chamfer,  etc.  The  PDDI  feature  entities  relate  specific  topology 
and  geometry  entities  to  a  given  feature  so  that  identifying  informatics 
for  that  feature  can  be  explicit  in  the  data,  a  necessary  condition  for  the 
support  of  automation. 

Geometry,  topology,  and  feature  information  are  often  collectively  referred 
to  as  "shape  information". 

The  other  innovation  from  this  class  of  data  exchange  efforts,  in  fact, 
from  the  PDDI  and  the  GMAP  efforts,  is  the  emphasis  on  having  the 
computerized  part  model  be  a  "complete"  model.  This  means  that  the  model 
contains  all  necessary  shape  and  non-shape  information  sufficient  to 
accomplish  a  given  function;  that  the  information  is  in  a  suitable,  i.e., 
automation-enabling,  computer  form;  and,  that  the  different  types  of 
information  are  associated  as  reqpjired.  For  example,  tolerance  information 
would  be  carried  in  a  form  directly  interpretable  by  a  computer  rather  than 


in  a  computerized  text  form  intended  primarily  for  interpretation  by  a 
human,  and,  this  information  would  be  associated  with  those  entities  in  the 
model  affected  by  the  tolerance.  Other  non-shape  entities  include 
administrative  entities  having  to  do  with  such  things  as  effectivity, 
specifications,  material,  notes,  etc.  Thus,  the  general  noticxi  associated 
with  a  complete  part  model  is  that  it  obviates  the  use  of  human-oriented 
drawings  and  other  paper  documents  as  a  necessary  means  of  cessing 
information  between  different  functions. 

It  is  interesting  to  note  that  the  first  tier  of  efforts  are  all  standards 
efforts,  ccMiceming  themselves  with  existing  systems  and  techniques,  while 
the  second  tier  of  efforts  are  research  and  development  p>rojects  concerning 
themselves  with  finding  out  how  things  should  be ,  and  ultimately 
intending  to  effect  change. 


THE  CXJNTENT  EMPHASIS  OF  PDES 


The  PDES  effort  will  reflect  this  dual  heritage,  and  will  extend  it.  It  is 
intended  that  the  PDES  effort  will  also  have  a  proactive  influence  on  both 
users  and  vendors. 

PDES  will  accommodate  the  wireframe  models,  the  familiar  generative 
surfaces,  and  the  drawing  representations  as  in  the  efforts  in  the 
standards  class.  But  the  driving  force  of  PDES  will  be  the  accommodation 
of  solids  modelling  and  a  complete  product  model,  as  is  characteristic  of 
the  efforts  in  the  research  and  development  class.  The  spirit  of  PDE^  will 
be  to  accommodate  in  a  computer-sensible,  functional,  integrated  form,  all 
of  the  types  of  information  necessary  to  perform  a  given  application. 

In  some  cases,  we  will  have  to  look  to  PC^  technical  working  committees  to 
define  and  relate  the  necessary  information.  In  other  cases,  such  as  for 
the  CAM-I  and  the  PDDI  efforts,  and  hopefully  the  GMAP  effort,  formally 
documented  results  will  be  made  available  to  the  PDES  committees,  or  at 
least  there  will  be  a  carryover  of  manpower.  Such  results  would  be 
examined  within  PDES,  and  could  be  expected  to  be  modified  and/or  extended 
in  order  to  achieve  a  consensus  view. 

PDES  will  extend  the  heritage  from  the  standards  efforts  and  the  research 
and  development  efforts  by  providing  a  means  for  an  organization  to 
communicate  its  product  breakdown  structure.  This  implies  accommodating 
such  notions  as  part,  subassembly,  assembly,  version,  effectivity,  release, 
etc.,  and  also  accommodating  the  natural  correspondence  between  these  kinds 
of  items  and  the  configuration  docunents,  test  data,  change  directives, 
etc.,  that  pertain  to  these  items.  Many  questions  remain  to  be  answered 
here.  For  example,  a  way  must  be  found  to  relate  the  product  breakdown 
structure  to  the  PI^S  file  or  files  representing  that  product  (as  when  a 
model  has  to  be  spread  over  several  files,  or  several  models  are  contained 
in  one  file),  and  to  do  this  in  a  way  that  will  serve  diverse  companies 
that  have  diverse  needs  in  this  area. 


THE  PDES  METHODOLOGY  AND  ITS  CHALLENGES 


The  distinguishing  characteristics  of  the  PDES  methodology  reflect  recent 


developments  in  data  base  and  information  systems  in  general.  They  also 
reflect  techniques  used  and  experience  gained  In  other  data  exchange 
efforts.  The  PDES  methockjlogy  is  significantly  different  from  the  IGES 
methodology. 

The  PDES  methodology  involves:  a  three-layer  architecture  similar  to  the 
three-schema  framework  for  data  base  management  systwns  as  identified  by 
ANSI/X 3/SPARC;  reference  models;  formal  languages;  and  coordination  with 
other  standards  efforts. 

Three-layer  Architecture 

The  three- layer  architecture  is  similar  to  the  three-schema  framework  in 
which  external,  conceptual,  and  internal  schemas  are  identified.  In  that 
framework,  the  conceptual  schema  comprises  the  unique  central  descripticxs, 
from  the  standpoint  of  the  enterprise,  of  the  meaning  of  the  data,  and  the 
relationships  among,  and  constraints  upon,  the  data.  It  embodies  the 
"rules  of  the  business".  This  description  is  ccxnputer  independent,  i.e., 
it  is  conceptual.  The  external  schema  represents  the  manner  in  which 
individual  users  and  applications  need  to  view  the  data  represented  by  the 
conceptual  schema.  Each  external  schema  can  therefore  be  derived  from  the 
one  conceptual  schema.  The  internal  schema  represents  the  actual  physical 
computer  storage  structure  being  used  to  store  and  access  the  data. 

Within  PDES,  the  three  layers  corresponding  to  these  three  schemata  are  the 
logical  layer,  the  application  layer,  and  the  physical  layer. 

The  application  layer  will  contain  the  descriptions  and  combinations  of 
information  peculiar  to  various  application  areas.  Information  modelling 
techniques  {or,  data  modelling  techniqxjes,  as  they  may  sometimes  be  called) 
vill  be  used  to  formally  express  what  the  required  pieces  of  information 
and  their  relationships  are  for  a  given  application  area.  These  models  are 
examples  of  what  are  termed  "reference  models".  (Several  application  area 
reference  models  have  been  produced  as  part  of  current  PM^  proof  of 
concept  work,  described  in  more  detail  in  a  later  section.  In  that  work, 
both  the  ICAM  IDEFl  and  the  Nijessen  Information  Analysis  Model  (NIAM) 
information  modelling  techniques  have  been  used.) 

This  layer  will  be  supported  by  application  siJogroups  such  as  the  standing 
subcommittees  now  in  IGES:  Advanced  Geometry,  Electrical,  Mechanical,  AEC, 
FEM,  Drafting,  etc.  The  challenge  here  will  be  to  actually  do  the 
modelling,  then  to  manage  the  networking  of  the  models  into  "clusters" 
depending  on  the  product  under  consideration.  Consistency  and  sufficiency 
within  each  cluster  “ust  be  insured.  The  modelling  itself  will  be  a 
challenge  because  the  application  of  information  modelling  techniques  to 
production  artifacts  seems  to  be  a  new  area. 

The  purpose  of  the  logical  layer  is  to  provide  a  consistent, 
compter-independent  description  of  the  data  constructs  that  will  contain 
the  information  to  be  exchanged.  Both  generic  and  application-specific 
constructs  are  expected  to  be  identified.  The  central  challenge  here,  and 
perhaps  in  the  entire  PDES  effort,  will  be  to  devise  and  carry  out  a 
conceptualization  and  integration  methodology  by  which  a  minimally 
redundant  set  of  generic  data  structures  and  relationships  can  be  produced. 
That  is,  this  set  must  be  as  lean  as  possible,  and  at  the  same  time 


sufficient  to  support  the  wide  range  of  applications.  Some  experience  will 
be  needed  to  be  able  to  settle  cm  such  a  roe thcxio logy,  but  it  will  likely  be 
a  combination  of  a  bottom-up  approach  (i.e.,  abstracting  from  information 
about  individual  application  areas)  and  a  top-dcjwn  approach  (i.e.,  deducing 
needed  structures  and  relationships  starting  from  some  global 
classification  schema  for  product  data).  Another  cl^llenge  will  be  to 
build  into  the  methodology  the  flexibility  of  being  able  to  consistently 
extend  the  schema  to  acccxnmodate  new  applications.  Establishing  mcdelling 
technique  recjuirements  is  also  expected  to  be  challenging. 

The  physical  layer  corresponds  to  the  internal  schema  and  will  be  concerned 
with  the  data  strxictures  and  data  formats  for  the  exchange  file  itself. 
The  main  challenge  here  will  be  to  establish  and  maintain  efficiency  in 
such  areas  as  file  size  and  processing  time. 

Reference  Models 


A  reference  model  for  some  universe  of  discourse  is  a  model  that  collects 
together  the  necessary  pieces  of  information  and  also  their  relationships 
to  each  other.  The  notion  includes  some  mechanism,  usually  graphical,  for 
describing  the  pieces  of  information  and  the  relationships. 

Reference  modelr  will  be  used  throughout  the  PDES  architecture.  The 
purpose  is  to  promote  thoroughness  in  domain  analysis  and  precisicn  in 
definition  and  corranunication  of  information,  especially  between  different 
layers.  Examples  of  two  types  of  application  area  reference  models, 
produced  using  state  of  the  art  information  modelling  techniques,  have  been 
given  above.  These  techniques  feature  a  graphic  form  inasmuch  as  they  are 
to  support  communication  between  humans,  and  also  feature  a  computer-based 
language  structure  inasmuch  as  they  are  to  support  computer  level 
operations.  This  feature  allows  the  use  of  computer  tools  for  use  with 
reference  models.  Eor  example,  it  would  seem  to  be  an  absolute  necessity 
that  the  reference  model  for  the  logical  layer  be  able  to  be  maintained 
using  computer  tools. 

The  first  challenge  here  for  a  standards  group  that  historically  has  been 
concerned  with  product  data  exchange  issues  is  simply  to  learn  something 
about  reference  models  and  information  modelling,  and  about  the 
requirements  that  any  particular  technique  must  satisfy  in  order  to  be 
useful.  Another  challenge  is  to  effectively  communicate  the  substance  of 
these  issues  to  people  who  are  familiar  with  information  modelling,  but  are 
probably  not  familiar  with  product  data  exchange,  and  to  do  this  in  a  way 
that  results  in  new  talent  being  brought  to  bear  on  our  problems. 

Formal  Languages 

Formal  languages  will  be  used  for  the  definition  of  data  structures  and  for 
the  PDES  file  syntax.  Emphasis  will  be  on  languages  with  context-free 
grammars  so  that  parsers  can  be  built  more  simply. 

Coordination  With  Other  Standards 


A  final  characteristic  of  the  PDES  methodology  will  be  its  relationship 
with  other  standards  efforts,  both  national  and  international.  How  data  is 
represented  within  PDES,  as  well  as  what  data  is  represented  will  be 


coordinated  with  other  efforts  to  insure  compatability  and  to  minimize 
duplication.  For  example/  there  already  has  been  cormnunication  between 
PDFS  and  X3H3  groups  concerning  minimizaticwi  of  duplicaticxj  in  connectiwi 
with  graphics  presentation  data.  Another  area  open  to  potential 
coordination  is  the  drafting  area. 

Some  of  the  motivation  for  PDFS  having  these  characteristics  can  be  traced 
to  other  data  exchange  efforts.  The  PDDI  effort  used  the  lESFl  information 
modelling  techniqi»  developed  within  ICAM.  The  PDDI  methodology  also 
emphasized  the  development  of  a  conceptual  schema  described  by  a  formal 
language,  separation  of  physical  data  structure  from  the  meaning  of  the 
data,  and  a  physical  file  structure  baaed  on  a  formal  language. 

In  addition  to  this,  experience  from  the  IGES  efforts  has  shown  that 
segmentation  of  the  development  of  a  standard  along  the  lines  of  the 
three-level  architecture  would  be  a  desirable  thing.  In  the  IGES  efforts, 
there  was  no  explicit  segmentation.  One  result  was  that,  in  the  course  of 
pursuing  new  application  areas,  application-oriented  people  were  being  held 
responsible  for  things  outside  their  area  of  expertise,  such  as  the 
formulation  of  physical  data  structures.  Another  result  was  that  there  was 
no  one  explicitly  charged  with  maintaining  a  global  viewpoint  toward  the 
entity  set  and  toward  the  consistency  of  the  makeup  of  new  entities.  Thus, 
for  example,  relationships  between  application-specific  and  generic 
entities  may  not  be  consistent.  In  some  cases  the  application  specific 
entity  may  be  primary,  while  in  other  cases  the  generic  entity  may  be 
primary.  Along  the  same  lines,  it  was  difficult  to  insure  that  the  generic 
entity  set  was  kept  as  lean  and  minimally  redundant  as  possible. 


PDFS  VERSION  1.0  -  SCHEDULE  AND  AWTICIPATED  CONTENTS 


The  target  date  for  a  draft  PDFS  Version  1.0  document  is  December  31,  1986. 
While  additions  and/or  deletions  may  yet  occur.  Version  1.0  contents  as  of 
this  time  are  as  follows: 

Application  Layer: 

1.  Geometry  And  Solid  Modelling  -  Wirefrcime,  Surfaces,  B-Rep,  CSG 

2.  Presentation  -  Viewing  pipeline.  View  Mechanism,  Text  Definition 

3.  Mechanical  -  Several  classes  of  parts  modeled,  including  the  classes  of 
machined,  turned,  flat  plate,  and  sheet  metal 

4.  Electrical/Electronic  -  Schematics,  Printed  Wiring  Board  Physical 
Design 

5.  Manufacturing  -  Administrative  data.  Tolerance  Model 


6.  AEC  --  HVAC  Distribution  Model 


7.  FEM  -  Functional  capability  of  IGES  Version  3.0  plus  some 
postprocessing  capability 

Logical  Layer  ^  Develop  conceptualization  and  integration  methodology,  and 
apply  to  application  reference  models 

Physical  Layer  -  Develop  ASCII  file  format  for  a  single  PDES  file 


PDES  PROOF  OF  CONCEPT  WORK  NCW  UNDER  WAY 

A  PDES  proof-of-concept  and  general  learning  exercise  has  been  under  way 
since  January  of  this  year.  This  work  is  collectively  known  as  the  PDES 
Initiation  effort,  and  is  expected  to  be  completed  by  April,  1986.  The 
effort  will  involve  all  three  layers  of  the  architecture,  but  is  being 
administered  by  two  task  groups.  One  is  associated  with  the  logical  layer, 
and  is  chaired  by  J,  C.  Kelly  of  Sandia  National  Laboratories.  The  other 
is  associated  with  the  physical  layer,  and  is  chaired  by  W.  B.  Gruttke  of 
McDonnell  Douglas. 

The  goal  of  the  Initiation  work  for  the  physical  layer  task  group  is  the 
specification  of  a  file  structure  for  tl»  PDES  exchange  form.  The  current 
(second)  draft  of  the  specification  specifies  the  file  strvicture  as  being 
language  based,  described  by  an  unambiguous,  context  free  grammar  expressed 
in  Bachus  Nauer  form.  The  specification  draws  heavily  on  previous  PDDI 
experience  in  this  area. 

The  Initiation  work  for  the  logical  layer  is  divided  into  two  tasks.  The 
goals  of  the  first  task  are  to  illustrate  that  a  conceptual  schema  can  be 
developed  in  support  of  a  specific  application  area,  and  then  to 
communicate  this  schema  to  the  physical  layer  using  a  Data  Specification 
Language  (DSL).  This  initial  conceptual  schema  will  draw  on  reference 
models  for  flat  plate  mechanical  parts,  wireframe  geometry,  and  graphic 
presentation  that  have  been  developed  as  part  of  this  task.  The  master 
reference  model  for  the  conceptual  schema  will  use  the  Nijssen  Information 
Analysis  Model  (NIAM)  information  modelling  technique,  with  the  DSL 
description  being  generated  manually  from  this.  The  DSL  description  of 
this  conceptual  schema  is  scheduled  to  go  to  the  physical  layer  group  on 
September  15.  Present  status  is  about  two  weeks  behind  this  schedule. 

The  goals  of  the  second  task  are  to  illustrate  that  the  initial  conceptual 
schema  can  be  sequentially  augmented  in  a  consistent  manner  to  support 
additional  application  areas,  and  then  to  communicate  the  augmented  schema 
to  the  physical  layer  group.  Four  application  area  reference  models  have 
been  developed  for  this  task.  They  are  in  the  areas  of:  Electrical,  FEM, 
Tolerancing,  and  AEC/HVAC.  All  of  these  models  use  the  IDEFl  information 
modelling  technique  with  the  exception  of  the  AEC  model,  which  uses  NIAM. 

(IDEFl  is  an  entity-attribute-relationship  modelling  technique,  and  NIAM  is 
a  binary  relationship  modelling  technique.  See  the  document  entitled 
"Concepts  And  Terminology  For  The  Conceptual  Schema  And  The  Information 
Base",  published  as  SC21-N197  by  ISO/TC97/SC21/WG5-3  for  examples  of  the 
use  of  different  modelling  techniques  to  describe  a  conceptual  schema.) 


The  master  reference  nrodel  for  this  task  will  also  use  the  NIAM  technique. 
The  three  IDEFl  models  will  be  translated  into  NIAM  models  prior  to  the 
conceptualization  and  integration  phase.  Following  this,  the  master 
reference  model  will  be  translated  into  EBL  as  in  the  first  task.  It  is 
expected  that  communication  of  this  DSL  description  to  the  physical  layer 
group  will  occur  approximately  December  1. 

The  spirit  of  the  initiation  work  is  that  we  will  do  the  beat  job  possible 
within  or  nearly  within  the  scheduled  time,  and  then  will  examine  and 
evaluate  the  products  of  our  efforts  and  our  methodologies,  and  for  PDFS 
longer  term  efforts  will  retain  what  is  good  and  discard  what  is  not. 

Additional,  more  detailed  information  concerning  the  Logical  Layer 
Initiation  work  is  contained  in  the  session  handout. 


THE  PDES  SPECIFICATION  -  SUMMARY 


1.  PDES  is  being  developed  to  support  industrial  automation.  It  will  deal 
with  the  entire  range  of  product  data  and  will  represent  the  L® 
position  internationally  in  the  quest  for  a  single  standard. 

2.  PDES  content  will  emphasize  solid  modelling,  complete  product  models, 
and  product  breakdown  structure.  It  is  intended  that  PDES  will  have  a 
proactive  influence  on  both  users  and  vendors. 

3.  PDES  Version  1.0  in  draft  form  is  targeted  for  December  31,  1986. 

4.  The  PDES  methodology  is  significantly  different  from  the  IGES 
methodology,  and  offers  many  challenges.  It  is  based  upon  a 
three-layer  architecture,  reference  models,  conceptualization  and 
integration,  and  formal  languages. 

5.  Proof  of  concept  work  is  currently  under  way  and  is  known  as  the  PDES 
Initiation  effort.  Content  and  methodology  beneficial  to  long  range 
PDES  work  will  be  kept. 

6.  Many  fundamental  PDES  topics  are  yet  to  be  widely  discussed.  Examples 
are  requirements  on  pre  and  post  processors  for  effective 
implementation  of  PDES,  requirements  on  user  databases  to  allow  full 
advantage  of  PDES,  and  interplay  between  these. 
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TOPIC  AREAS 
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PDES  SCOPE  AND  OBJECTIVES,  Cont’d 
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The  U.  S.  intention  is  that  PDES  and 
be  identical. 
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THE  PDES  RELATIONSHIP  TO  lOES  Cont'd 
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DATA  -  SAY,  BY  A  HUMAN  AT  A  GRAPHICS  TERMINAL 
NOT  AUTOMATION  -  ENABLING. 
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THE  PDES  METHODOLOGY  AND  ITS  CHALLENGES 
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Coordination  with  other  standard's  efforts. 


THE  ANSI/X3/SPARC  DATABASE  ARCHITECTURE 
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THF  iJES  METHODOLOGY,  cont'd. 
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originate  and  consistently  expand  the  set  of 
data  constructs. 


THE  PDES  METHODOLOGY.  Cont’d 
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the  exchange  file  itself.  The  challenge  will 
be  to  establish  and  maintain  efficiency  in 
file  size  and  processing  time. 
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Coordination  with  other  standards  is  to 
minimize  duplication. 
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THE  PDES  SPECIFICATION 
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Federal  Computer  Conference 
September  9 >10/ 11,  1985 
Washington  Convention  Center 


Theme  Track;  Tying  It  All  Together 
Session;  Product  Data  Exchange 
Topic;  Product  Data  Exchange  Standard  (PDES) 

Speaker;  J.  C.  Kelly »  Sandia  National  Laboratories 


Charter 


Of  The 


PDES  Logical  Layer  Initiation  Task  Group 


Submitted  By: 

J.  C.  Kelly 

Sandia  National  Laboratories 
Chairman,  Logical  Layer  Initiation 
Task  Group 


July  30,  1985 


Note:  The  following  material  constitutes  operational  papers  describing 
work  in  progress  or  work  projected  to  be  done  as  part  of  the  pres 
Initiation  Effort#  and  does  not  comprise  any  official  policy  on  behalf  of 
any  IGES  or  PDES  Committee#  especially  with  regard  to  the  contents  of 
future  versions  of  PMIS  and  the  methodology  by  which  those  versions  might 
be  produced.  Actual  work  performed  as  part  of  the  Logical  Layer  portion  of 
the  Initiation  Effort  may  vary  depending  on  schedules  and/or  the  amount  of 
volunteer  manpower  that  participating  companies  are  able  to  devote  to  the 
tasks  described. 


Charter  Of  The  TOES  Logical  Layer  Initiation  Tiisk  Group 


The  PDES  Logical  Layer  Initiation  Task  Group  is  an  ad  hoc  subconsnittee 
of  the  POES  Oonmittee.  This  Task  Groutp  will  perfonn  work  as  described 
below  as  part  of  the  PnSS  Initiation  effort. 

The  purposes  of  the  work  of  this  Task  Group  are: 

1.  Examine  the  possibility  and  feasibility  of  developing  PDES 
according  to  the  three  level  ANSI/X3/SPARC  architecture  as 
suggested  in  the  second  PDES  report. 

2.  Establish  logical  layer  content  which  potentially  could  serve  as  a 
baseline  for  future  PDES  development. 

The  tMO  main  tasks  of  this  Task  Group  are: 

1.  Illustrate  that  a  conceptual  schema  can  be  developed  in  support  of 
a  specific  application  area*  and  communicate  the  stnjcture  of  this 
schema  to  the  POBS  Physical  File  Structures  and  Formal  Languages 
Task  Group. 

2.  Illustrate  that  this  conceptual  schema  can  be  augmented  in  a 
non-redundant  manner  on  an  application-by-application  basis. 

The  first  task  will  contribute  to  illustrating  the  use  of  all  three 
levels  of  tne  three  level  architecture.  The  second  task  will 
illustrate  that  the  ccmceptual  schema  can  be  incrementally  augmented  as 
the  need  arises  -  a  characteristic  of  the  PDES  envirorunent. 

Each  task  will  result  in  a  communication  of  the  conceptual  schema 
content  to  the  Physical  Pile  T^sk  Group.  A  Data  Specification  Language 
will  be  used  for  this.  Communication  for  the  first  task  will  be 
approximately  mid-September#  1985#  and  communication  for  the  second 
task  will  be  approximately  November  1#  1985. 

Requests  will  be  made  of  application  groups  to  compose  reference  models 
to  be  used  in  the  second  task.  These  groups  could  conceivably  be  based 
in  existing  IGES  Subcommittees#  or  could  be  ad  hoc. 

A  final  report  will  be  written.  The  report  will  describe  and  document 
what  work  was  performed#  and  will  make  recommendations  based  this 
experience.  The  general  time  frame  for  this  report  is  January  1#  1986. 

The  Task  Group  will  meet  as  required  in  order  to  accomplish  its  work# 
and  will  periodically  report  on  its  progress. 


lask  Overview 


Task  1  A  conceptual  schema  will  be  developed  to  support  the 
mechanical  design  of  flat  plates  %d.th  circular  holes.  Wireframe 
geometry  will  be  used.  The  schema  will  support  some  user-view 
presentation  (viewing)  scenarios  pertinent  to  this  area  of  mechanical 
design. 

The  wireframe  geometry  entities  and  the  presentation  entities  will  be 
developed  as  part  of  this  task.  A  reference  model  describing  the 
conceptual  schema  will  be  produced.  The  Information  Analysis  (lA) 
information  modeling  methcxJology  will  be  used  for  this  reference  model, 
and  the  Data  Specification  Language  (DSL)  description  of  the  conceptual 
schema  %/ill  be  based  on  this  reference  model. 


Task  2  Four  Application  Task  Groups  will  be  contacted  to  compose 
reference  models.  These  models  will  be  used  one  at  a  time  to 
cumulatively  augment  the  conceptual  schema  produced  in  the  first  task. 
A  reference  model  depicting  the  "final"  conceptual  schema  will  be 
produced/  as  will  a  mapping  illustrating  how  each  application  makes  use 
of  the  conceptual  schema.  The  cumulative  augmentation  of  the 
conceptual  schema  will  involve  integration  in  the  sense  that  a  minimim 
number  of  "generic"  entities  and  strnjctures  will  be  sought  to  support 
the  common  needs  of  the  various  applications. 

The  integration  work  is  the  focal  point  of  this  task.  The  Information 
Analysis  (lA)  modeling  methodology*  and  associated  Software  Tools  (ST)* 
will  be  used  to  support  this  work,  (Specifically,  lAST,  a  CDC  software 
product  in  the  possession  of  those  who  will  be  doing  the  integration 
work,  will  be  used.)  In  order  to  provide  a  common  footing  for  the 
integration  work,  and  to  make  possible  the  use  of  the  supporting 
software,  each  reference  model  from  an  Application  Task  Group  will  be 
translated  into  an  equivalent  lA-based  reference  model,  and  entered 
into  lAST.  The  resulting  translated  reference  model  will  be 
scrutinized  from  a  "Quality  Assurance"  point  of  view.  A  liason  from 
the  referring  Application  lask  Group  will  assist  in  understanding  and 
possibly  refining  the  reference  model,  thereby  closing  the  QA  loop. 

lA  will  be  used  to  describe  the  final  conceptual  schema,  and  also  to 
illustrate  how  each  application  nakes  use  of  the  conceptual  schema.  As 
in  the  first  task,  the  Data  Specification  Language  description  of  the 
conceptual  schema  will  be  based  on  the  lA  reference  model  of  the 
conceptual  schema. 


The  Application  Reference  Models  Are: 

1.  Mechanical  Design  »  Flat  Plates  With  Circular  Holes 

2.  Electrical  Design  Schematics 

3.  Tolerancing  -  Tolerances  In  Y14.5M  And  ISO  1101  and  1660 

4.  Finite  Element  -  Finite  Element  Environment 

5.  AEG  -  AEC/HVAC 

Recommendations  For  General  PDES  Evaluations^  recommendations#  and 
experiences  based  on  this  vrork  will  inclvxle: 

1.  An  evaluation  of  the  three  level  architecture  as  an  environment  for 
developing  PDEIS. 

2.  Recommendations  for  a  logical  layer  integration  methodology. 

3.  Recommendations  for  application  layer  information  modeling 
techniques. 

4.  Experiences  with  the  use  of  automated  tools. 


PDES  Logical  Layer  Initiation  Task  Group 


I.  Bodnar,  CDC 

D.  Briggs,  Boeing 

R.  Brown,  Hughes  (New  Member) 

E.  Clapp,  IBM,  Wireframe  Geometry  Task  Leader 

S.  DePauw,  caterpillar.  Flat  Plate  Design  Task  Leader 
R.  Gale,  DACOM 

D.  Heramelgam,  ITI 

J.  C.  Kelly,  Sandia,  Chairman 
P.  Kennicott,  GE 

H.  Ladd,  DuPont  (New  Member) 

D.  Schenck,  McDonnell-Douglas,  DSL  Task  Leader 
D.  Theilen,  Allied/Bendix,  Logical  Layer  Integration  Task  Leader 
D.  Winfrey,  DEC,  Presentation  Task  Leader 
J.  Zimmerman,  Allied/Bendix 


Application  Layer  Tasks  Initiated  By  Request  Of  The  Logical  Layer 
Initiation  Task  Group  And  Their  Coordinators  With  The  Logical  La^r 

1.  Mechanical  Design  -  Reference  Model  For  Flat  Plates 

S.  dePauw  -  Caterpillar,  Task  Leader 
D.  Henanelgam  -  ITI 

2.  Electrical  Design  -  Reference  Model  For  Schematics 

C.  Parks  -  General  Dynamics,  Task  Leader 

P.  Kennicott  -  General  Electric 

Work  Supported  By:  IGES  Electrical  Subcommittee 

3.  Tolerancing  -  Reference  Model  For  Tolerances  In  Y14,5M 

R.  Oolsher  -  IGES  Data  Analysis,  Task  Leader 
B.  Burkett  -  McDonnell-Douglas 

work  Supported  By:  IGES  Drafting  Information  Model  WG 

4.  Finite  Element  -  Reference  Model  For  FE  Qivircximent 

R.  Ivey  -  Westinghouse,  Task  Leader 

B.  Freeman  -  Allied/Bendix 

Work  Supported  By:  IGES  FEM  Subcommittee 

5.  AEC  -  Reference  Model  For  AEC/HVAC 

F.  Stahl,  IBM,  T^sk  Leader 
P.  Rourke,  Newport  News  Shipbuilding 

J.  Turner,  University  Of  Michigan 
Work  Supported  By:  IGES  AEC  Subcommittee 


J.  C.  KELLY,  Chairman 
SANDIA  NATIONAL  LABORATORIES 


THE  ANSI/X3/SPARC  DATABASE  ARCHITECTURE 
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A  single  internal  schema. 
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PDES  Initiation  Logical  Layer  Methodology 
Principal  Author;  John  Zimmerman,  Allied/Bendix  Aerospace,  Kansas  City 


The  primary  mission  of  the  Logical  Layer  Initiation  Effort  is  to  develop 
the  definition  of  the  logical  entities  required  to  meet  the  needs  of  all 
applications  within  the  initiation  scope.  This  includes  "generic  entities" 
which  are  required  by  two  or  more  applications  and  "application  specific 
entities"  which  are  used  in  cxily  one  application  area.  Ttiis  set  of 
entities  and  their  relationships  is  referred  to  as  the  conceptual  schema. 

The  Primary  goal  of  the  PDES  Initiation  Logical  Layer  Methodology  is  to 
guide  the  Logical  Layer  Initiation  Effort  in  the  development  of  the 
conceptual  schema  for  T^sk  1  and  'teak  2  of  the  Pr»S  Initiation  Effort  as 
described  in  the  PDES  Logical  Layer  Charter. 

The  following  are  key  success  factors  for  this  methodology; 

1.  Maximize  usage  of  state-of-the-art  conceptual  modelling  techniques  and 
tools. 

2.  Support  the  integration  of  the  three  PDES  architectural  layers 
(application,  logical,  and  physical)  as  described  in  "Ttie  Second  PDES 
Report" . 

3.  Maximize  the  usage  of  human  resources  in  development  of  the  conceptual 
schema  by  defining  and  establishing  project  roles. 

4.  Simplify  the  methodology  as  much  as  possible. 

5.  Give  the  methodology  growth  potential  so  that  it  can  support  future 
PDES  efforts. 

6.  Maximize  the  potential  of  the  conceptual  schema  to  serve  as  a  central 
resource  from  which  all  other  PDES  forms  can  be  computed. 


Methodology  Overview 


Refer  to  the  accompanying  figure  for  a  graphical  overview  of  the 
methodology.  The  numbering  of  the  models  is  consistent  with  the  US 
Position  paper  "Reference  Models,  Development  Methodology,  and  Entity 
Subsets  for  STEP"  submitted  to  IS0/TC184/SC4/WG1  by  the  US  TAG. 

The  methodology  is  broken  into  three  phases: 

PHASE  1;  Pre-conceptualization.  In  this  phase  all  afplication  area 
reference  models,  regardless  of  modelling  form,  are  reduced  to  binary  form 
to  maximize  potential  for  conceptualisation  and  integration.  When  these 
binary  models  are  verified  against  the  original  application  area  model  they 
are  considered  "qualified". 


PHASE  2:  Conceptualization  and  Integration.  In  this  phase  conceptual 
entities  and  relationships  are  discovered.  An  integrated  conceptual  model 
is  built  from  which  cam  be  derived  {via  mappings)  any  application  area 
reference  model.  A  conceptual  architecture  will  be  built  that  models  all 
conceptual  categories.  This  architecture  will  be  stored  in  a  dictionary 
which  will  be  developed  in  this  stage.  It  is  in  this  phase  that  the 
maximum  potential  of  the  conceptual  schema  will  be  realized. 

PHASE  3;  Post-Conceptualization.  In  this  phase  the  binary  conceptual 
schema  will  be  conditioned  in  preparation  for  development  of  the  physical 
file  format.  The  conceptual  schema  is  grouped  into  a  nested  record  form 
called  Data  Specification  Language  (DSL).  This  DSL  form  is  the  ultimate 
deliverable  to  the  physical  file  layer.  The  ultimate  source  of  the  DSL 
will  always  be  the  binary  conceptual  schema. 


Methodology  Details 
PHASE  1;  Pre-conceptualization 

Goal:  To  maximize  the  conceptualization  and  integration  potential  of  the 

application  area  models. 

Input:  Application  area  reference  models. 

Deliverable:  A  computerized  binary  model  verified  to  be  equivalent  to  the 
original  application  area  reference  model. 

Description:  This  phase  of  the  methodology  conditions  the  application  area 
reference  model  in  preparation  for  conceptualization  and  integration.  In 
the  PDES  Initiation  Effort  application  area  reference  models  may  be  of  any 
form  that  has  a  reasonable  degree  of  rigor.  The  conditioning  process 
converts  these  diverse  forms  into  a  single  standard  semantic  form.  The 
standard  semantic  form  is  the  binary  model.  Specif icallyj  Nijssen's 
Information  Analysis  Model  (NIAM)  will  be  used. 

All  application  area  reference  models  are  manually  reduced  to  binary  form 
and  entered  into  an  electronic  data  base  (CDC's  Information  Analysis 
Support  Tool  -  lAST).  This  model  database  is  echoed  back  to  the 
application  area  in  the  form  of  natural  language  sentences  derived  manually 
from  the  binary  model  and  in  computer-generated  relational  structures.  The 
relational  structures  are  used  for  the  validation  of  binary  models  that 
have  been  translated  from  record-oriented  application  area  models.  The 
natural  language  sentences  are  returned  to  the  application  area  for 
approval.  The  binary  model  is  considered  to  be  "qualified"  when  the 
natural  language  sentences  are  approved  and  the  relational  structures  are 
verified  to  be  equivalent  to  the  original  record-oriented  model.  It  is 
presumed  that  most  application  area  reference  models  will  be  record  or 
relational ly  oriented. 

Even  though  the  computer  generated  relational  model  may  be  useful  in 
follow-on  PDES  efforts,  its  only  use  in  the  Initiation  Effort  is  the 
validation  of  record-oriented  reference  models.  The  deliverable  of  this 
phase  is  the  binary  conceptual  model. 


PHASE  1  roles  identified: 


1.  Model  translators 

2.  Model  software  support  tool  technician 

3.  Liasion  between  application  and  logical  layer  to  support  natural 
language  verification. 

4.  Data  modelling  expert  who  is  able  to  verify  equivalency  of  the  computed 
form  with  the  original  application  area  reference  models. 

PHASE  2:  Conceptualization  and  Integration 

Goal:  To  build  the  conceptual  schema  and  maximize  its  potential  as  a 

central  resource  in  the  PDES  Initiation  Effort  aux3  to  develop  a  conceptual 
dictionary  tool  to  hold  the  components  of  a  conceptual  architecture. 

Input:  d;ialified  binary  models  of  the  application  areas. 

Deliverable:  A  computerized  conceptual  schema  in  binary  form,  and  a 

computerized  data  dictionary  containing  the  conceptual  architecture  and 
conceptual-to-application  area  mappings. 

Description:  It  is  in  this  phase  that  the  actual  conceptualization  and 

integration  occurs.  The  reader  is  encouraged  to  refer  to  Appendix  A  which 
is  an  excerpt  from  "The  Second  PDES  Report".  It  overviews  and  describes 
the  three  layer  architecture.  This  phase  is  the  most  challenging  of  the 
three  phases  of  the  logical  layer  methodology.  It  is  from  this  phase  that 
the  crucial  aspects  of  extensibility,  stability,  resilience,  and  technology 
independence  will  be  confronted.  Some  cultural  resistance  to  this  phase  is 
to  be  expected  as  it  seems  to  draw  out  the  process  of  getting  to  the 
ultimate  PDES  deliverable,  the  physical  file  format. 

As  an  initiating  effort,  this  phase  will  start  with  popular  concepts  and 
notions  of  concept\»l  schema  that  have  been  derived  from  ANSI/X3/SPARC, 
ISO/TC97/SC5/WG3,  NASA  IPAD,  2knd  M)DI.  The  logical  layer  team  realizes 
that  conceptualization  across  the  broad  spectrum  of  product  data 
represented  in  the  application  models  is  a  new  area  for  standards  work. 
The  team  also  realizes  that  the  conceptualization  of  engineering  and 
manufacturing  artifacts  is  fairly  new.  The  team  expects  to  adapt  the 
principles  of  conceptualization  as  they  apply  to  business  systems  to 
engineering  arxJ  manufacturing  artifacts  as  much  as  possible,  but  realizes 
that  new  conceptualization  principles  must  be  develoj^. 

PHASE  2  is  divided  into  two  sub-phases,  PHASE  2A  and  PHASE  2B.  PHASE  2A  is 
concerned  with  the  building  of  the  conceptual  schema  from  detailed 
application  area  reference  models  (in  a  general  sense  a  bottom-up  process). 
PHASE  2B  deals  with  a  conceptual  schema  architecture  that  will  give 
high-level  structure  for  the  guidance  of  PHASE  2A  activities  ( in  a  general 
sense  a  top-down  process) .  It  is  anticipated  that  tb«  software  support 
tools  for  PHASE  2A  and  2B  will  be  separate  but  manually  coordinated.  The 
primary  support  tool  for  PHASE  2A  will  be  lAST.  The  primary  support  tool 
for  PHASE  2B  may  possibly  be  a  relational  data  base  system  such  as  RIM. 


PHASE  2A  Description:  The  construction  of  a  conceptual  schiema  is  not  a 

well-defined  process  and  this  methodology  will  serve  only  as  a  guide. 

The  following  tasScs  are  identified: 

1.  Develop  a  set  of  entity  categories.  To  the  greatest  extent  possible 
these  categories  will  be  generic  in  that  they  may  be  used  across  a 
broad  set  of  applications.  Wiese  categories  can  be  discovered  as  the 
qualified  application  reference  models  are  being  reviewed  (bottom-up) 
or  an  initial  set  can  be  adopted  provisionally  from  other  sources  such 
as  PDDI. 

2.  Develop  a  set  of  structural  categories.  A  stricture  in  this  case  is  a 
recognizable  pattern  of  inter-related  entities  that  appears  in  multiple 
application  area  models.  The  conceptual  schema  will  consist  of  generic 
entities,  generic  structures,  and  application  specific  structures. 

3.  Examine  each  qualified  applies ticxi  area  model  and  attempt  to  break  it 
completely  into  generic  entities,  generic  atnxrtures,  and  application 
specific  entities.  This  partitioning  of  the  application  area  model  is 
recorded  in  the  data  dictionary  (this  tool  is  created  by  PHASE  2B 
activities.) . 

4.  Once  the  application  area  model  has  been  completely  translated  into  the 
conceptual  schema,  logical  layer  workers  in  conjun''‘-ion  with 
application  layer  worlcers  verify  that  the  original  application  area 
model  can  be  recovered.  It  is  the  job  of  the  logical  layer  worker  to 
be  familiar  with  the  generic  entitiies  and  structures.  It  is  the  job 
of  the  application  area  worker  to  find  a  best  fit  for  his  application 
entities.  A  cooperation  effort  between  logical  and  application  workers 
is  crucial  in  this  task. 

5.  Once  the  application  area  model  is  verified  to  be  recoverable  from  the 
conceptual  schema  all  mappings  must  be  defined  and  recorded  in  the 
dictionary.  The  logical  layer  team  may  possibly  not  be  concerned  in 
the  Initiation  Effort  about  formally  defining  these  mappings  although 
in  future  PMIS  efforts  it  will  become  more  important.  In  this  case 
narrative  sentences  may  suffice. 

Make  any  adjustments  to  the  conceptual  schema  (hopefully  an  addition  of 
a  new  generic  entity,  not  a  change  to  an  existing  generic  entity).  It 
may  be  necessary  to  regressively  test  all  previous  application  area 
models  for  recoverability  after  a  major  change  to  the  conceptual 
schema. 


6. 


PHASE  2B  Description:  This  activity  is  similar  to  the  strategic  data 

planning  activity  for  the  development  of  a  large  integrated  business 

information  system.  The  tasks  are  as  follows: 

1.  Adopt  a  conceptual  schema  architecture,  ^pendix  B  is  an  excerpt  from 
the  US  position  paper  "Reference  Models#  Development  Methodology,  and 
Entity  Subsets  for  STEP"  submitted  to  ISO/TC184/SC4/WG.  The  subsets 
referred  to  in  this  paper  are  the  major  architectural  components  we  are 
looking  for.  These  architectural  components  will  be  dictionary 
categories.  Refer  to  Appendix  B  for  a  complete  rationalization  for  the 
need  of  a  conceptual  schema  architecture. 

2.  Develop  a  conceptual  dictionary  tool  to  hold  the  architectural 
components.  It  would  be  advantageous  if  this  dictic»iary  were  an 
integral  part  of  the  lAST  but  the  PDES  Initiation  Effort  delivery 
schedules  will  not  permit  this.  It  is  suggested  that  a  simple 
relational  tool  such  as  RIM  be  used  provisionally.  The  following 
dictionary  categories  would  be  a  start:  Life  Cycle  Stage,  Discipline, 
Functional  Area,  Application  Area,  Class,  Entity,  Version.  This 
initial  set  of  categories  should  greatly  assist  in  giving  the 
conceptiial  schema  development  project  direction  and  cohesiveness.  An 
effort  should  be  made  to  keep  the  number  of  dictionary  categories  as 
small  as  possible.  Obviously  new  categories  must  be  added  to  cover  the 
mapping  of  the  conceptual  schema  to  application  area  models. 

PHASE  2  roles  identified: 

1.  Model  software  support  tool  technician 

2.  Liason  between  application  layer  and  logical  layer 

3.  Dictionary  administrator 

4.  Conceptual  model  administrator 

5.  Data  architect  who  has  broad  knowledge  of  engineering  and  manufacturing 
life  cycle,  disciplines,  and  applications. 

6.  Data  analyst 

PHASE  3:  E>03t-Conceptualization 


Goal :  To  condition  the  conceptual  schema  in  preparation  for  conversion  to 
the  PDES  exchange  format. 

Input:  The  binary  conceptual  schema  and  mappings  to  application  area 

models. 

Deliverable:  A  ccxnplete  specification  of  the  conceptual  schema  in  Data 

Specification  Language  (DSL). 

PHASE  3  Description:  The  purpose  of  this  phase  is  to  convert  the  binary 
conceptual  schema  into  a  grouped  logical  record  form  (a  structural  form). 
This  form  is  still  neutral  as  it  has  not  yet  been  committed  to  a  physical 
form.  The  Data  Specification  Language  (DSL)  has  been  chosen  as  the  PDES 


Initiation  Effort  standard  structural  form.  It  was  chosen  because  its  form 
(nested  array)  naturally  models  the  hierarchical  structure  of  most 
engineering  and  maunfacturing  artifacts.  It  is  also  a  compact  textual  form 
suitable  for  documentation. 

The  major  task  is  the  actual  conversion  of  the  binary  conceptual  schema 
into  DSL.  For  the  PDES  Initiation  Effort  this  will  be  done  manually  but  it 
is  suggested  for  follow  on  efforts  that  this  ccxiversion  be  automated. 

The  DSL  specification  of  the  conceptual  schema  represents  the  official 
documentation/  however  the  binary  conceptual  schema  will  always  be  the 
source  from  which  the  DSL  specification  is  generated.  The  binary 
conceptual  schema  is  the  principle  resource  for  the  Initiation  Effort. 

PHASE  3  role  identified: 

1.  Translator  from  binary  conceptual  schema  to  DSL 


;^pendix  A 


4.4 


THE  ABCHTTECTURB  OF  THE  PDES 


The  task  of  developing  a  data  standard  for  industries  using  CAD/CAM  is  a 
huge  undertaking.  The  problem  must  be  broken  down  into  smaller  pieces  in 
order  to  make  progress.  Modularization  is  the  separation  of  a  process  into 
small,  separate  functions  with  precise  interfaces  between  the  functions. 
This  separation  makes  each  function  manageable  and  eases  maintenance 
since  changes  can  be  isolated  to  a  specific  function.  Modularization 
provides  flexibility  to  make  changes  since,  as  long  as  the  interface  between 
functions  remains  the  same,  one  function  cannot  tell  if  another  has  been 
changed  or  even  replaced.  Modularization  of  the  development  process  is  a 
philosophy  recommended  for  the  PDES  development.  That  is,  different 
groups  will  be  tasked  with  different  functions  of  the  design  process.  The 
function  of  data  analysis  and  design  will  be  partitioned  into  three  parts 
based  on  the  level  of  abstraction  of  the  data.  Thus,  the  application 
information  will  be  separated  f**om  the  conceptual  entity  definition  which 
will  be  separated  from  the  physical  definition.  Each  such  partition  will  be 
called  a  layer. 

As  alluded  to  above,  the  PDES  will  be  structured  into  a  three  layer 
architecture.  These  layers  correspond  almost  identically  with  the  layers  of 
schema  in  the  ANSI/X3/SPARC  three  schema  architecture  (cf.  appendix 
C.1.1)  for  defining  and  implementing  data  bases.  The  layers  are  described 
in  the  following  sections  and  illustrated  by  figure  4-3. 

4.4.1  ApplieationAlser  Layer 

In  the  chosen  architecture,  the  top  layer  is  the  user  or  application  layer. 
This  is  the  layer  at  which  the  ultimate  user  lives  and  thinks.  He  formulates 
his  data  requirements  in  his  own  terms  stating  concisely  what  he  needs.  He 
draws  from  his  own  experience  and  from  the  established  terms, 
conventions,  techniques,  and  methodologies  of  his  discipline.  He  isn't 
concerned  with  the  number  of  different  ways  that  a  single  thing,  event,  or 
phenomenon  can  be  represented.  He  isn't  concerned  with  analogous  notions 
used  by  different  application.  For  example,  he  doesn't  care  that  electrical 
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Figure  4-3.  Three  Layer  PDFS  Architecture 


and  piping  networks  share  much  in  common.  The  different  appUcaiion 
groups  such  as  Electrical  Products  or  Finite  Element  Modelir^  define  the 
information  relevant  to  their  application  and  model  the  interrelationships 
that  exist  between  the  informational  entities.  This  information  is  defined 
by  using  a  reference  or  information  model.  The  reference  model  helps 
structure  and  validate  the  data  in  the  application. 

This  layer  of  the  Standard  contains  as  many  different  applications  and 
entities  within  those  applications  as  there  is  apparent  need  for. 

4.4.2  Logical/Cooeeptual  Layer 

The  second  layer  is  the  logical  or  conceptual  layer.  This  is  where  the  data 
content  for  the  set  of  generic  entities  is  defined.  This  set  should  be  a 
normalized,  minimumly  redundant  set  (cf.  sec.  4.3)  that  supports  the 
information  defined  by  the  applications. 

At  this  layer,  logical  commonality  will  be  sought  across  ail  applications. 
Things,  events,  and  phenomena  which  are  identical  except  for  the  renaming 
of  components  wdl  be  treated  as  being  logically  identical.  Thus  the 
connectivity  of  a  piping  network  and  an  electrical  network  will  be 
considered  logically  identical.  Also  at  this  layer,  there  will  be  exactly  one 
way,  not  several,  to  represent  a  directed  line  segment,  perhaps  by  a  point 
together  with  a  direction  vector. 

At  this  layer,  complex  things,  events,  and  phenomena  will  be  constructed 
of  less  complex  things,  events,  and  phenomena  whenever  possible.  The 
purpose  is  to  maximize  the  utilization  of  conversion  processors  for  simpler 
entities  in  the  process  of  converting  a  complex  entity. 

Similarities  in  the  ^formation  requirements  of  different  applications  wiU 
be  integrated  into  single  conceptual  entities.  The  integration  of  different 
application  requirements  will  control  the  definition  of  redundant  entities 
and  will  help  to  ensure  a  consistent,  coherent  entity  set. 
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The  entity  definitions  at  this  layer  will  be  in  a  logical  form.  That  is,  the 
data  content  of  an  entity  will  be  defined  but  not  the  physical  format.  As 
described  in  Section  4.2,  a  definition  language  will  be  defined  in  which  the 
entities  will  be  specified.  This  language  will  be  a  formal,  rigorous  language 
which  will  help  reduce  ambiguity  as  is  present  in  the  IGES.  In  addition, 
reference  models  will  be  built  to  verify  consistency  among  the  definitions. 

The  data  content  of  the  set  of  application-specific  entities  will  also  be 
defined  at  this  layer.  These  entities  will  be  defined  in  the  same  rigorous 
manner  as  the  generic  entities  above,  that  is  with  their  data  content 
specified  using  a  formal  definition  language  and  reference  models. 

It  is  expected  that  the  concepts  of  the  logical  layer  wiU  be  organized  as 
the  product  data  itself  is  organized.  This  organization  is  discussed  in 
section  2.1  and  is  outlined  in  figure  2-1. 

4.4.3  Physical/Intcsmal  Layer 

The  bottom  layer  is  the  physical  or  internal  layer.  This  layer  contains  one 
or  more  actual  file  format  definitions.  It  consists  of  the  description  of  the 
sections,  records,  fields,  caquencing,  and  associated  formats  for  the 
exchange  file.  Again,  a  formal  definition  language  will  be  used  to  reduce 
ambiguity.  A  reference  model  will  be  built  for  each  format  definition. 

Since  the  content  is  separated  from  the  format,  multiple  formats  can  be 
defined  for  logical  entity  definitions  which  only  affect  the  read/ write 
routines  of  a  processor.  Thus  the  majority  of  a  PDES  processor  will  be 
independent  of  the  file  format. 
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6.0  Subsets  of  the  Conceptual  Schema 

One  or  more  mechanisms  are  required  within  the  Conceptual  Schema  for 
defining  subsets  of  entities.  These  will  be  used  in  a  variety  of  ways  for 
creating,  understanding  and  using  STEP,. 

6.1  Requirements  for  Subsets 

6.1.1  Hunan  Understanding  of  the  Standard 

0  To  understand  any  large  collection  of  facts  (such  as  the 
Conceptual  Schema),  a  human  must  categorize  the  facts  into 
collections  (subsets)  which  are  intellectually  manageable. 


-11- 


0  The  names  on  the  subsets  can  be  used  to  understand  the  scope  of 
the  collection. 

0  Subsets  for  the  Conceptual  Schema  act  as  a  directory  for  users 
or  logical  modelers  (developers)  to  find  existing  entities  that 
perform  a  function. 

0  An  entity  can  be  better  understood  if  other  members  of  its 
subset  and  the  nature  of  the  subset  are  known. 

0  Users  can  match  an  application  with  others  which  can  do  the  same 
or  related  jobs  based  upon  Conceptual  Schema  subsets. 

6.1.2  Functional  Requirements 

0  Subsets  provide  an  abbreviation  efficiency  within  the  reference 
models.  For  example,  when  a  certain  attribute  may  be  any  valid 
curve,  we  can  specify  the  class  "CURVE"  rather  than  enumerating 
all  valid  curves. 

0  Schema  management  procedures  may  be  used  to  propagate  common 
attributes  to  every  member  of  a  class. 

0  Subsets  can  be  used  by  validation  checking  software  to  certify 
translators  and  other  appl ications. 

6.1.3  Management  of  Development 

0  Subsets  of  the  Conceptual  Schema  represent  subsets  of  the  work 
required  in  developing  the  standard.  They  can  be  used  to  define 
the  scope,  development  milestones,  and  subdivision  of  labor  and 
expertise. 

0  A  uniform  system  of  subsets  may  be  useful  in  recognizing  voids 
in  the  standard.  For  example,  if  analysis  reference  models  had 
been  defined  for  mechanical  and  architectural  disciplines,  but 
not  for  electrical,  the  void  would  be  obvious. 
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0  Versions  of  the  standard  could  be  regarded  as  natural , 
time-dependent,  subsets. 

6.2  Identification  of  Subsets 

The  best  method  of  subset  identification  would  be  to  exercise  the 
methodology  discussed  in  Section  4  and  use  logical  layer  processing  to  help 
discover  natural  functional  subsets.  However,  logical  layer  processing 
would  be  enhanced  by  a  pre-existing,  coordinated  set  of  subsets  selected 
from  common  knowledge  of  data,  functions,  and  applications  within  the 
CAD/CAM  community.  This  set  will  undergo  continual  review  and  updating  as 
the  standard  develops  -jn  fbe  logical  layer  deliberation. 

6.3  Proposed  Subset  Types  of  the  Conceptual  Schema 

To  address  all  of  the  above,  a  network  of  subsets  of  several  types  are 
required.  The  structural  relationships  between  the  types  is  depicted  in 
Figure  3.  The  types  are  defined  as  follows: 

Versions  -  Time  sequenced  sets  of  the  entire  standard.  Each 
version  would  contain  all  entities  and  subset 
structures  valid  in  a  particular  release  of  the 
standard. 

Functional  Area  -  A  high  level  set  of  application  area  subsets  can  be 

used  for  a  particular  function.  It  can  be  regarded  as 
a  two  dimensional  matrix  of  engineering  disciplines  and 
product  life  cycle  as  shown  in  Figure  4.  Each  cell  on 
the  matrix  defines  a  functional  area  and  may  contain 
multiple  application  area  subsets.  This  chart  and 
concept  is  adapted  from  document  (4).  In  that  document 
the  matrix  is  part  of  a  4  dimensional  matrix  called 
"Level".  The  term  "Level"  derived  primarily  from 
another  dimension  which  classified  geometric 
complexity.  That  concept  is  part  of  a  following  class 
structure. 
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Subset  Types  in  the  Conceptnii^^  Schema 
As  Beia-caa  to  Entities 


PIGUPE  3 
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FITNCTIONAL  AREAS 


FIGURE  4 


Application  Area  -  A  set  of  entities  and  classes  for  modeling  the  concepts 

of  a  particular  application  (such  as  forging  design)  or 
related  applications  (such  as  forging  design  and 
manufacture).  Application  area  subsets  may  apply  to 
multiple  Functional  Areas;  e.g.  FEM  Application  Area 
will  be  used  for  analysis  in  several  disciplines.  ^ 
application  area  may  contain  other  application  areas; 
e.g.,  manufacturing  forging  area  may  be  different  from 
but  may  include  design  forging  area.  A  combination  of 
version  and  application  area  could  be  used  to  specify 
capability  of  an  application. 

Class  -  A  set  of  entities  or  classes  (but  not  both)  which  are 
semanticly  similar.  Each  entity  is  contained  in 
exactly  one  class.  Each  class  is  contained  in  zero  or 
one  higher  level  class. 

A  class  may  be  generic  or  application  area  specific. 
This  means  it  may  be  used  in  multiple  application  areas 
or  may  simply  collect  the  entities  which  are  unique  to 
•  a  single  application  area. 

In  Figure  3  the  relations  between  subset  types  and  entities  are 
represented  as  single  diamond  leaders  for  one-to-many  relations  and  double 
diamond  leaders  for  many-to-many  relations. 

See  Appendix  B  for  the  recommended  classes  and  entities  for  STEP. 

6 . 4  Storing  Subset  Definitions 

One  method  for  defining  subsets  within  the  conceptual  schema  is  the 
"class"  structure  defined  in  the  Data  Specification  Language  in  WGi  N20. 
Additional  methods  may  be  required,  particularly  for  versions. 
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